System and method for distributed real time authorization of payment transactions

ABSTRACT

Systems and methods enable the real-time authorization of payment transactions initiated by personal and mobile computing devices. In one embodiment, a financial account server associated with a payment recipient, or payee, is configured to receive a payment data envelope from a payee computing device. The payment data envelope can further include information that allows for the authentication of the payee and payer identities as well as payment restrictions or instructions. The payee financial account server processes the payment data envelope and transmits the envelope to a financial account server associated with the payer. The payer financial server authenticates the payer identification, authorizes the payment transaction, and transmits a transaction status message to the payee financial server, which in turn transmits the message to the payee computing device.

CROSS REFERENCE TO RELATED APPLICATION

This divisional application claims priority from pending U.S.nonprovisional application Ser. No. 14/227,770 filed Mar. 27, 2014, theentirety of which is incorporated herein.

TECHNICAL FIELD AND BACKGROUND

The present invention relates generally to the field of paymenttransactions, and more particularly, to systems and methods fordistributed, real-time authorization of payment transactions initiatedby a mobile device. The systems and methods are capable performing thefunctions of existing centralized card networks in a unique andefficient manner, and the systems and methods further permit theimplementation of the many features and advantages offered by moderncomputing devices when conducting payment transactions.

Traditional payment transactions between a merchant and a consumer oftenuse credit or debit cards that are processed by a card reader or otherpoint of sale (“POS”) device. The POS device reads static, preprogramedinformation from a magnetic strip on the card and transmits theinformation to an issuing bank through an acquirer (merchant) bank and acentralized card network (e.g., VISA™ or MASTERCARD™). The issuing bankapproves or declines the transaction and, if approved, transmits apayment to the acquirer bank through the card network. The issuing bankalso transmits an approval or decline notice to the POS device that isrouted through the card network and the acquirer bank. The card networktypically subtracts an interchange fee before routing the payment to theacquirer bank.

Traditional methods of conducting payment transactions have thedisadvantage that the information exchanged cannot be customized foreach transaction, and the methods are not capable of taking advantage ofopportunities provided by recent advances in computing and mobiletechnology. To illustrate, it is now possible to initiate paymenttransactions using personal computers or cellular “smartphones” that arecapable of transmitting and receiving a variety of useful informationduring a payment transaction, such as coupon codes, paymentinstructions, and additional security features for authenticating aconsumer's identity (e.g., biometric information or machine gesturerecognition).

It would, therefore, be advantageous to provide payment transactionsystems and methods that are capable of processing customizable paymenttransactions initiated and conducted by computing devices. It would alsobe advantageous to provide distributed payment transaction systems andmethods that permit direct communication between financial serviceproviders, such as acquirer and issuing banks, without the need to routepayment transactions through a centralized card network that deductsinterchange fees.

The systems and methods of the present invention enable the newgeneration of payment transactions initiated and performed by computingdevices and address the requirements needed to bring the suchinnovations to market by providing a low-cost, highly scalable, andresilient distributed banking and payment platform capable of performingreal-time authorization of payment transactions initiated by mobile andother computing devices.

SUMMARY

According to one embodiment of the invention, a method and system ofauthorizing payment transactions is provided. The method includesreceiving, by a first server associated with a payee financial account,a payment data envelope transmitted by a payee computing device. Thepayment data envelope includes payer data, encrypted payee data, andpayment instructions. The payee financial account server decrypts theencrypted payee data, verifies the payee identity by comparing the payeedata in the received payment data envelope to payee data stored in adatabase, and then transmits the payment data envelope to a secondfinancial server associated with the payer. The payee financial serverthen receives a transaction status message from the payer financialserver indicating whether the payment transaction was authorized.

In another aspect of the invention, the payer data includes a payeraccount alias that is transmitted by the payee financial account serverto a routing key and management server. In return, the payee financialaccount server receives, from the routing key and management server,routing information for transmitting the payment data envelope to thepayer financial account server.

According to another embodiment of the invention, a method and systemincludes receiving, by a first server associated with a payer financialaccount, a first payment data envelope transmitted by a second serverassociated with a payee financial account. The payment data envelopeincludes encrypted payer data, payee data, and payment instructions. Thepayer financial account server decrypts the encrypted payee data andverifies the payer identity by comparing the payer data in the firstpayment data envelope to payer data stored in a database. The payerfinancial account server also determines a whether the payment isauthorized or declined. The payer financial server then generates atransaction status message that is transmitted to the payee financialaccount server.

In one aspect of the invention, the payee data includes a payee accountalias that is transmitted by the payer financial account server to arouting key and management server. In return, the payer financialaccount server receives, from the routing key and management server,routing information for transmitting the transaction status message tothe payee financial account server.

Another aspect of the invention provides for the receipt of a secondpayment data envelope containing payer data transmitted by an identitymanagement server associated with the payer and/or generated by a payercomputing device. The payer financial account server verifies the payeridentity by: (1) comparing the payer data in the second payment dataenvelope to payer data stored in a database; and (2) comparing the payerdata in the first payment data envelope to the payer data in the secondpayment data envelope.

In yet another aspect of the invention, the encrypted payer datacomprises cancellable biometric information.

In one embodiment of the invention, the payer financial account serverauthorizes a payment transaction by determining whether data in thepayment data envelope complies with one or more payment restrictionsassociated with the payer and stored in a database on the server.Payment restrictions may include, for instance: a predetermined upperlimit on the payment amount; a geographic limitation on the locationwhere the payer can initiate a payment transaction; a limitation on thetypes of products for which a payer can initiate a payment transaction;and/or a limitation on the identity of the payment recipient for whomthe payer can initiate a payment transaction.

One embodiment of the invention includes a system with a first processorassociated with a payee financial account and a second processorassociated with a payer financial account. Each processor is coupled todata storage device that includes non-transitory computer-readablemedium with computer-readable code for instructing the processors. Whenexecuted, the computer-readable code instructs the first processor tostore payee data to a first data storage device. The first processorthen associates the payee data with payee transaction data. The firstprocessor receives a first payment data envelope associated with apayment transaction from a payee device. The first payment data envelopeincludes a payee alias, a payee shared secret, and crypto data,including encrypted payee data and encrypted payee transaction data. Thefirst processor decrypts the encrypted payee data from the payment dataenvelope using the payee shared secret and retrieves the stored payeedata using the decrypted payee transaction data. The first processorcompares the decrypted payee data with the retrieved payee data. Basedon the comparison, the first processor verifies the identity of thepayee, and based on the verification, generates an IP address requestmessage that includes a payer alias. The first processor transmits theIP address request message and the payer alias to an RKM server. Inreturn, the first processor receives a second server IP address from theRKM server. The second server IP address is used to transmit the firstpayment data envelope to the second processor.

In another aspect of the invention, the first payment data envelopeincludes an instruction data array, and the second processor generates atransaction status message with a transaction flag having a value ofauthorized or declined. The transaction status message is transmittedfrom the second processor to the first processor. When the firstprocessor receives a transaction status message with a transaction flagof authorized, the first processor creates a temporary database recordof the payment transaction that is used to update a payee accountbalance. When the first processor receives a transaction status messagewith a transaction flag of declined, the first processor transmits thefirst payment data envelope to alternate consumer account server basedon the instruction data array.

Another embodiment of the invention also includes a system with a firstprocessor associated with a payee financial account and a secondprocessor associated with a payer financial account. Each processor iscoupled to data storage device that includes non-transitorycomputer-readable medium with computer-readable code for instructing theprocessors. When executed, the computer-readable code instructs thesecond processor to store to a second data storage device, a consumerPIN and biometric information. The second processor associates theconsumer PIN and biometric information with consumer paymentinformation. The second processor receives a first payment data envelopeassociated with a payment transaction from the first processor. Thefirst payment data envelope includes a payee alias, a consumer sharedsecret and crypto data including encrypted biometric data, encryptedPIN, and encrypted payment information. The second processor decryptsthe encrypted consumer PIN, biometric information and paymentinformation from the first payment data envelope using the consumershared secret. The second processor retrieves the stored consumer PINand biometric information using the decrypted payment information andcompares the decrypted consumer PIN and biometric information with theretrieved consumer PIN and biometric information. Based on thecomparison, the second processor validates the payment transaction, andbased on the validation, generates a transaction status messagecorresponding to the validation. The second processor transmits thepayee alias to the RKM server and receives a first IP address for thefirst processor. The second processor utilizes the IP address totransmit the transaction status message to the first processor.

In another feature of the invention, the system processors are furtherconfigured to perform operations that include the second processorreceiving a second payment data envelope from an identity managementserver and storing payer data to a second data storage device. Thesecond processor associates the payer data with the consumer paymentinformation. As part of authorizing the payment transaction, the secondprocessor verifies the payer identity by comparing payer data in thefirst payment data envelope with payer data in the second payment dataenvelope. Alternatively, as part of authorizing the payment transaction,the second processor can retrieve payment data and verify the payeridentity by comparing payer data in the second payment data envelopewith the retrieved payer data.

Yet another embodiment utilizes the second processor to store one ormore payment restrictions to the second data storage device andassociate the one or more payment restrictions with the payer. Thesecond processor determines whether data in the first payment dataenvelope or a second payment data envelope complies with the one or morepayment restrictions. Payment restrictions may include, for instance: apredetermined upper limit on the payment amount; a geographic limitationon the location where the payer can initiate a payment transaction; alimitation on the types of products for which a payer can initiate apayment transaction; and/or a limitation on the identity of the paymentrecipient for whom the payer can initiate a payment transaction.

Other embodiments utilize a first payment data envelope that includespayment instructions that are used to determine the amount paid as partof the payment transaction. The payment information can include, forinstance, the cost of goods or services along with a gratuity amount tobe added to the cost amount or include a discount amount that should besubtracted from the transaction cost amount. The second processor usesthe payment instructions and payment information to determine the finalpayment amount that is then included in the transaction status messagetransmitted to the first processor by the second processor.

BRIEF DESCRIPTION OF THE DRAWINGS

Features, aspects, and advantages of the present invention are betterunderstood when the following detailed description of the invention isread with reference to the accompanying figures, in which:

FIG. 1 is a diagram of a distributed, real-time payment transactionauthorization system according to one embodiment;

FIG. 2 is a data flow diagram illustrating an exemplary paymenttransaction authorization system and method according to one embodimentof the invention;

FIG. 3 is an exemplary payment data envelope illustrating payer data;

FIG. 4 is an exemplary payment data envelope illustrating payer data;

FIG. 5 is an exemplary payment data envelope illustrating payer andpayee data;

FIG. 6 is an exemplary payment data envelope illustrating payer andpayee data;

FIG. 7 is a data flow diagram illustrating an exemplary paymenttransaction authorization system and method according to one embodimentof the invention;

FIG. 8 is a data flow diagram illustrating an exemplary paymenttransaction authorization system and method according to one embodimentof the invention;

FIG. 9 is a data flow diagram illustrating an exemplary paymenttransaction authorization system and method according to one embodimentof the invention; and

FIG. 10 is a data flow diagram illustrating an exemplary distributedpayment authorization system.

DETAILED DESCRIPTION

The present invention will now be described more fully hereinafter withreference to the accompanying drawings in which exemplary embodiments ofthe invention are shown. However, the invention may be embodied in manydifferent forms and should not be construed as limited to therepresentative embodiments set forth herein. The exemplary embodimentsare provided so that this disclosure will be both thorough and completeand will fully convey the scope of the invention and enable one ofordinary skill in the art to make, use, and practice the invention.

Disclosed herein are systems and methods for distributed, real-timeauthorization of payment transactions. Although the embodimentsdescribed herein are generally described with reference to exemplarycommercial transactions where a consumer purchases goods or servicesfrom a merchant, those skilled in the art will recognize that thesystems and methods are applicable to payment transactions generally.Payment transaction types can include, but are not limited to, sales ofgoods or services, cancellations, product returns or refunds,credit-based transactions, and promotions.

As used herein, the term “payee” generally describes an individual orentity receiving payment during a transaction, such as a merchant,vendor, retailer, or other seller of goods and services. The term“payer” is intended to generally describe a person or entity that makesa payment during a transaction, such as a purchaser of products orservices. The term “payer” may be used interchangeably with the terms“consumer” or “purchaser.” Those skilled in the art will recognize thatthe roles of a payer and payee in any transaction can be reversed ashappens when, for example, a customer returns a product to a merchantfor a refund.

As shown in FIG. 1, a system according to one embodiment of the presentinvention generally includes a computing device (e.g., anInternet-enabled device) operated by a consumer 101, a computing deviceassociated with a payee 102, an identity management service 106 (“IdM”),and a computer system 200 associated with one or more financial serviceproviders (“FSP”). The FSP computer system 200 may include one or morenetwork computing devices, such as a financial server associated with apayee account 103, a financial server associated with a consumer account105, and a routing & key management (“RKM”) server 104, as well as oneor more computing devices associated with FSP employees (not shown).Various components of the FSP computing system 200 can be associatedwith different FSPs, such as when a merchant and consumer utilizefinancial accounts with separate FSPs.

The IdM service 106 can include one or more network computing device,such as a server, as well as one or more personal computing devices.Similarly, the payee computing device 102 can be an autonomous device,or it can be networked to a payee computing system (not shown) thatincludes one or more network computing devices, such as a server, aswell as other payee computing devices. A payee computing device can beassociated with one or more merchants, such as when an individual personoperates two separate businesses and utilizes the same payee computingdevice to process payment transactions for both businesses.Alternatively, a single merchant may utilize multiple payee computingdevices, such as a retailer with numerous sales associates who eachutilize a separate payee computing device to process paymenttransactions.

The system shown in FIG. 1 is not intended to be limiting, and one ofordinary skill in the art will recognize that the systems and methods ofthe present invention may be implemented using other suitable hardwareor software configurations. For example, the FSP computer system 200 mayutilize only a single server implemented by one or more computingdevices, or a single computing device may implement one or more of thepayee account server 103, consumer account server 105, RKM server 104,and/or the FSP employee computing devices. Further, a single computingdevice may implement more than one step of the method described herein;a single step may be implemented by more than one computing device; orany other logical division of steps may be used.

Any suitable computing device can be used to implement the consumercomputing device 101, the payee computing device 102, or the componentsof the FSP computer system 200. The consumer computing device 101, thepayee computing device 102, and the computing devices of the FSP system200 can include a processor that communicates with a number ofperipheral subsystems via a bus subsystem. These peripheral subsystemsmay include a memory subsystem (e.g., random access memory), a storagesubsystem (e.g., optical, mangnetic, or solid-state storage), user inputand output subsystems (e.g., a keyboard, mouse, computer monitor,touch-screen display, microphone, or speaker), a networking subsystem,and a communication subsystem. By processing instructions stored on astorage device or in memory, the processors may perform one or moresteps of the methods described herein.

In a preferred embodiment, the consumer computing device 101 and thepayee computing device 102 are portable electronic devices that includeone or more integrated software applications configured to provide,among other features, a user interface configured to facilitate paymenttransactions and two-way communication with other electronic devices.The consumer computing device 101 and the payee computing device 102 canbe any type of suitable portable electronic device, including, forexample, a cellular phone, a tablet computer, or a laptop computer. Theportable electronic device can also be an application-specific deviceconfigured for processing payments, such as a merchant checkoutterminal, debit/credit card reader, or virtual wallet.

The software applications integrated with the consumer and payeecomputing devices 101 & 102 are a program, function, routine, applet, orsimilar module that performs operations on the computing devices toimplement the steps of the methods disclosed herein. For example, theapplication integrated with the consumer computing device 101 may be oneor more of a digital wallet application, a coupon application, amerchant loyalty account application, or any other suitable applicationconfigured for processing payment transactions. The applicationintegrated with the payee computing device 102 may be a mobile checkoutapplication, a debit/credit card reader application, or any othersuitable point of sale application configured for processing paymenttransactions. The consumer computing device application and the payeecomputing device application provide a user interface that outputs dataand information to, and accept inputs from, a user. Types of data andinformation processed by the applications include text, images, audio,video, or any other form of information that can exist in acomputer-based environment. The user interface can include variousdisplay screens that output data to a user as well as functions foraccepting user inputs and commands, such as text boxes, pull-down menus,radio buttons, scroll bars, or other suitable functions known to one ofordinary skill in the art.

The integrated software applications interface with a communicationsubsystem to provide for a secure connection with other electronicdevices. Possible connections include a local area network, a wide areanetwork, an intranet, an Internet connection, a mobile telephonenetwork, a personal area network, or any other suitable connection. Theone or more communication subsystems may include a wirelesscommunication system configured to communicate through radio frequency(“RF”), WI-FI (e.g., wireless local area network products based on theInstitute of Electrical and Electronics Engineers 802.11 standards),near field communications (“NFC”), Bluetooth, or Low Energy Bluetooth.In one example, a consumer has the ability to make purchases with theconsumer computing device 101 by using NFC to wirelessly establish asecure link with the payee computing device 102, which can be connectedto (i) a payee computer system configured to facilitate commercialtransactions, and (ii) a FSP computer system 200.

A consumer is able to link multiple personal financial accounts to theconsumer computing device 101, including checking and savings accounts,credit card accounts, store-specific charge accounts, and electronicfunding service accounts (e.g., PAYPAL™). In this manner, a consumer isable to utilize applications integrated with the consumer computingdevice to purchase goods and services using any of the linked financialaccounts. The integrated application can also provide other functionspermitting the consumer to receive account balance information, makewithdrawals, or deposit funds, among other features.

The consumer computing device 101 and payee computing device 102 includea secure element 109 to ensure confidentiality of sensitive consumer orpayee data (e.g., credit card or bank account numbers) duringtransmission between electronic devices. The secure element 109 existswithin a removable smart chip or a secure digital card or is embeddedwithin a fixed chip on the computing device. The secure element 109includes an integrated software application that performs the functionsdescribed herein. The secure element 109 is capable of storing encryptedconsumer or payee data 313 & 332 and allowing only trusted applicationsto access the data. In this manner, the secure element 109 permitssoftware applications to interact with certain functions in the secureelement 109 while protecting sensitive data stored in the element 109.

In an exemplary embodiment, the secure element 109 generates an accountalias 312 & 331 for sensitive consumer or payee data; though, theaccount alias 312 & 331 could also be entered by the consumer orprovided by a merchant. The alias 312 & 331 is passed to the softwareapplications and transmitted between devices rather than the unencryptedconsumer data. The aliases 312 & 331 are identifiers for sensitiveconsumer or payee data that cannot be used to make a payment withoutvalid crypto data 313 & 332 that corresponds to the aliases 312 & 331.The aliases 312 & 331 do not need to be stored securely because paymentsmade with an alias are not accepted unless the corresponding crypto data313 & 332 is also supplied.

In the embodiment shown in FIG. 2 depicting a purchase made by aconsumer, the crypto data 313 is generated using a shared secret 314that operates on the alias 312 or sensitive consumer data. The sharedsecret 314 can be, for example, a symmetric key representing a password,a random number, a counter value that is incremented for each aliasvalue, or any other suitable value. The shared secret 314 is distributedto the secure element 109 at the time the device is manufactured as wellas loaded into the payee computing device 102 and/or the financialservers 103 & 105 before a payment transaction is initiated.Alternatively, the shared secret 314 is created at the start of acommunication session using a key-agreement protocol.

Those of ordinary skill in the art will recognize that theabove-described embodiments are not intended to be limiting, and thesystem and methods described herein can be implemented using othersuitable means for establishing a secure connection, such aspublic/private key encryption, digital signature authentication, or theWi-Fi Protected Access 2 standard, among others. Further, in embodimentswhere the payee is making a payment to the consumer, such as during thereturn of merchandise to a merchant, skilled artisans will recognizethat the process is reversed, and the payee generates crypto data 332using a shared secret 333 that operates on a payee alias 331. The payeeshared secret 333 can be the same or different from the consumer sharedsecret 314. In the case of public/private key encryption, the public keywill be transmitted as a shared secret 314 & 333 in the payment envelope301.

In one or more embodiments, when a consumer initiates a request to makea payment transaction using sensitive consumer data, the financialserver determines whether the combination of the alias 312 and cryptodata 313 are valid using the shared secret 314 that is known to thesecure element 109 and the financial server. The financial server usesthe shared secret 314 to verify the alias 312 and the crypto data 313.The financial server receives the alias 312 from the consumer computingdevice 101 via the payee computing device 102 and combines the alias 312with other information, as described above. The financial server canthen generate the same crypto data 313 using the shared secret 314 andreceived data and compare the result with the received crypto data 313.If the comparison indicates that the values are the same, then thepayment transaction is authorized and proceeds as normal. Otherwise, thetransaction can be denied or authorization can be withheld pending thereceipt of additional information.

Similarly, if a payee initiates a request to make a payment transactionusing sensitive payee data, the financial server determines whether thecombination of the payee alias 331 and payee crypto data 332 are validusing the shared secret 333. The financial server receives the alias 331from the payee computing device 102 via the consumer computing device101 and combines the payee alias 331 with other information. Thefinancial server can then verify the transaction by generating the samepayee crypto data 332 using the payee shared secret 333 and receiveddata and comparing the result with the received payee crypto data 332.

The flow of data during a consumer payment transaction according to oneembodiment is illustrated in FIG. 2. During a payment transaction, theconsumer computing device 101 connects to the payee computing device102. At 201, the payee computing device 102 transmits transaction datato the consumer computing device 101 for display to a consumer.Transaction information can include, for instance, a productdescription, stock-keeping unit (“SKU”), product price, tax payment,merchant identifying information, coupon or discount codes,customer-loyalty information, customer preferences, warranties, productregistration information, a transaction identifier, or any otherinformation useful to the consumer.

The consumer computing device 101 displays the transaction informationto the consumer and requests payment transaction authorization andpayment instructions. In authorizing the payment transaction, theconsumer optionally specifies payment instructions. As an example, theconsumer can specify a gratuity amount; a discount code; the personalfinancial account from which the payment should be withdrawn orcredited; whether payment should be performed in installments amounts,and if so, the duration and amount of the payments; a merchant rating;or any nonstandard payment instructions capable of being processed bythe payee and/or FSP computer system 200.

Before transmitting 203 a payment instructions to the payee computingdevice 102, the consumer computing device 101 can optionally communicate202 with an IdM service 106 associated with the consumer. The IdMservice 106 is an account that permits authentication of the consumer'sidentity and management of the consumer's preferences or otherinformation. Examples include, but are not limited to, social mediaaccounts, employer accounts, or merchant loyalty accounts. The IdMservice 106 provides information to the consumer that is relevant to thepayment transaction, such as merchant ratings; cost comparisons; andpayment transaction rules, restrictions, or controls. The IdM service106 can also provide information useful for ensuring the security of thetransaction, such as cancellable biometric data, a personalidentification number (“PIN”), gesture recognition information,federated identification information, or geographic restrictions onwhere payment transactions can be authorized.

To illustrate, a consumer may have an IdM service account with his orher employer that utilizes an unique user identification and passwordand that is associated with an employer-issued credit card for thepayment of business expenses. The employer account may includepreferences, available discounts, or payment restrictions. Thus, theconsumer can be informed of whether the employer has a discountavailable through a particular merchant or whether the employer limitspurchasing authorization to particular merchants, products, geographiclocations, or spending limits.

After receiving authorization and payment instructions from theconsumer, a software application integrated with the consumer computingdevice 101 generates a secure payment envelope 301 that is stored to adatabase on the consumer computing device 101. The secure paymentenvelope 301 contains a variety of information to facilitateauthentication of the consumer and payee identities, authorization ofthe payment transaction, and the security of the data transmitted. Anexemplary payment envelope 301 generated by the consumer computingdevice 101 is illustrated in FIG. 3 and includes: (1) transaction data311; (2) a consumer account alias 312; (3) consumer crypto data 313; (4)a shared secret 314; and (5) a payment instruction data array 315.

In the event that the payee computing device 102 or one or morecomponents of the FSP computer system 200 are not configured to processpayment transactions using the inventive systems and methods disclosedherein, the secure payment envelope 301 may include additionalinformation to facilitate authorization of the payment transactionthrough traditional means, as shown in FIG. 4. The additionalinformation includes, for example: (1) credit card or debit card numbers316; (2) card expiration dates 317; and (3) or other information 318necessary for authentication, such as a consumer's address, zip code, orcard verification value (“CVV”).

At 203 a & 203 b, the consumer computing device 101 transmits thepayment envelope 301 and the consumer's payment transactionauthorization to the payee computing device 102 as well as to the IdMservice 106. The IdM service 106 can in turn transmit 207 the paymentenvelope 301 to the consumer financial server 105 to update theconsumer's account and facilitate authorization of the paymenttransaction, as described in more detail below. Alternatively, theconsumer computing device 101 can bypass the IdM service 106 andtransmit the payment envelope 301 directly to the consumer financialserver 105.

In processing the payment envelope 301, the payee computing device 102appends payee data to the envelope, as illustrated in FIG. 5. Theappended payee data includes information such as: (1) transaction data330; (2) a payee account alias 331; (3) payee crypto data 332; (4) ashared secret 333; and (5) an instruction data array 334. In the eventthat one or more components of the FSP computer system 200 or theconsumer computing device 101 are not configured to process paymenttransactions using the inventive systems and methods described herein,the secure payment envelope 301 may further include information topermit authorization of the payment transaction through conventionalmeans, as shown in FIG. 6. The additional information includes, forexample, merchant account information 335 relating to the payee'saccount with a FSP (e.g., an acquiring bank that contracts with themerchant to create and maintain an account that allows the merchant toaccept credit card and debit card payments).

The payee computing device 102 can further append nonsensitivetransaction data 306, such as a payer identification 342 or terminaldata 341 identifying the payee name, location, and merchantclassification. The nonsensitive transaction data 306 could be utilizedby the consumer's FSP or IdM service 106 to track the consumer'sspending habits. To illustrate, a family can have multiple membersutilizing a single checking account where each family member has aseparate consumer computing device 101 with an unique payeridentification 342. If a parent shares an account with a child, and thechild uses a consumer computing device 101 three times in a month andpurchases (i) $25 in movie tickets, (ii) $50 of gasoline, and (iii) $25in fast food, the payer identification 342 and merchant categories 341(i.e., terminal data) can be appended to the payment envelope 301 asnonsensitive data 306 during each payment transaction. This informationis stored to a database on the consumer financial server 105 or IdMservice 106 and can be displayed to the parent as a pie chart showingthat half of the child's expenditures went to dining and entertainmentand half went to transportation.

Turning again to FIG. 2, after processing the payment envelope 301, thepayee computing device 102 transmits 204 the payment envelope 301 to thepayee financial server 103 for storage and processing. The payee may beassociated with one or more financial accounts so that if the primarypayee financial account server is unavailable, the payment envelope 301can be routed to a secondary payee financial account server.

Upon receiving the payment envelope 301, the payee financial server 103retrieves the payee data from the payment envelope 301, including thepayee account alias 331 and the payee crypto data 332. The payeefinancial server unencrypts the payee crypto data 332 using the sharedsecret 314/333. The payee identity and transaction are authenticated by,for example, comparing payee and transaction information contained inthe received payment envelope 301 with information stored on the payeefinancial server 103. A payment request record is created and stored toa database on the payee financial server 103.

The payment envelope 301 is routed from the payee financial server 103to the consumer financial server 105 using information in the consumeraccount alias 312. As show in in step 205, the payee financial server103 can optionally obtain from a RKM server 104 additional informationuseful for communicating with the consumer financial server 105, such asan Internet Protocol (“IP”) address for the consumer financial server105 or a session “token” or “cookie.” A token is a packet of data thatcontains information identifying a series of related message exchangesand that can facilitate routing and authentication of the transmittedmessages. As an example, if the account alias 312 is a routing numberfor a personal financial account, the payee financial server 102 cantransmit the routing number to the RKM server 104 and receive in returnthe IP address of the consumer financial server 105 or a token forestablishing a secure communication session. The payee financial server103 can save the IP address, token, or other routing information to adatabase for faster processing until the token expires and thecommunication session with the consumer financial server 105 ends.

After the secure payment envelope 301 is transmitted 206 to the consumerfinancial server 105, the consumer financial server 105 retrieves theconsumer data from the payment envelope 301, including the payee accountalias 312 and the consumer crypto data 313. The consumer financialserver 105 unencrypts the payee crypto data 313 using the shared secret314, and a payment request record is created and stored to a database onthe consumer financial server 105. The consumer's identity isauthenticated and the payment transaction authorized by comparing datafrom the received payment envelope 301 with consumer or transaction datastored on the consumer financial server 105. If the consumer andtransaction data stored on the consumer financial server 105 matches thedata contained in the payment envelope 301, then the payment transactionis authorized and proceeds as normal. Otherwise, the paymentauthorization can be denied or authorization can be withheld pending thereceipt of additional information. If the payment transaction isauthorized, the consumer financial server 105 will memo post the paymenttransaction by creating a temporary database record of the paymenttransaction in the consumer's financial account for which a completeposting to update the consumer account balance will be done as part ofan end-of-day batch processing.

In one embodiment, the consumer financial server 105 authenticates theconsumer identity and authorizes the payment transaction by retrieving207 a copy of the payment envelope 301 or other consumer or transactiondata stored in a database on the IdM service 106 and comparing thisinformation with the payment envelope 301 received from the payeefinancial server 103. If the consumer and transaction data stored withthe IdM service 106 matches the data contained in the payment envelope301 received from the payee financial server 103, then the identity ofthe consumer is authenticated and the payment transaction is authorized.Authentication through the IdM service 106 is optional and can beperformed in addition to, or instead of, the authentication andauthorization performed by comparing data from the received paymentenvelope 301 with consumer or transaction data stored in a database onthe consumer financial server 105.

The consumer's identity can be authenticated using cancellablebiometrics, a preselected personal identification number (“PIN”),machine gesture recognition, or any other secure and independently knownconsumer data or combination of such data. The payment transaction canbe authorized or declined based on a variety of factors, including, forexample: (1) whether the consumer identity was properly authenticated;(2) whether the amount of the payment request exceeds the availableaccount balance; and (3) whether the transaction complies with anyrules, restrictions, or controls associated with the consumer's account.

Authentication of the consumer identity and authorization of a paymenttransaction can be better understood with reference to the followingsimplified example. When establishing a personal checking account or IdMservice account, a consumer can provide biometric information, like afingerprint, as well as conventional security information, like a PIN.Biometric information can be secured by making it “cancellable,” whichrefers to a systematic and repeatable distortion of the biometricinformation through known techniques, like salting or noninvertibletransforms. The consumer can also set one or more rules or restrictionsgoverning the authorization of payment transactions, such as permittingauthorization only within the zip code in which the consumer lives. Thedistorted biometric information is securely stored in a secure element109 of the consumer computing device 101, the consumer financial server105, and/or the IdM service 106. The PIN is also stored in a database onthe consumer financial server 105 and can optionally be stored on theconsumer computing device 101 or IdM service 106 or input by a consumerduring a payment transaction.

When authorizing a payment transaction through the consumer computingdevice 101, the cancellable fingerprint data, PIN, and checking accountnumber are encrypted using the shared secret 314 and stored in thecrypto data 313 of the payment envelope 301. The routing number of thechecking account is stored in the consumer account alias 312 of thepayment envelope 301. The payment envelope 301 is transmitted 203 a tothe payee computing device 102 and the IdM service 106, and the IdMservice 106 transmits the payment envelope 301 to the consumer financialserver 105.

The payee computing device 102 appends to the payment envelope 301nonsensitive data, such as the geolocation of the payee computing device103. The payee computing device 102 transmits 204 the secure paymentenvelope 301 to the payee financial server 103, which then transmits 206the payment envelope 301 to the consumer financial server 105. Toproperly route the payment envelope 301, the payee financial server 103transmits 205 the alias 312 (checking account routing number) to the RKMserver 104, which returns an IP address for the appropriate consumerfinancial server 105.

The consumer financial server 105 unencrypts the crypto data 313 usingthe shared secret 314, and compares the received cancellable biometricdata and PIN to the cancellable biometric data and PIN stored on theconsumer financial server 105 and associated with the consumer'schecking account. The consumer financial server 105 performs anadditional security check by comparing the cancellable biometric dataand PIN received from the payee financial server 103 to the cancellablebiometric data and PIN received from the IdM service 106. The consumerfinancial server 105 also compares the geolocation data contained in theterminal data 341 of the payment envelope 301 to the geographic zip coderestrictions associated with the consumer's account and stored in adatabase on the consumer financial server 105. The payment transactionis authorized if: (1) the cancellable biometric data and PIN receivedfrom the payee financial server 103 matches the corresponding datastored on the consumer financial server 105 and received from the IdMservice 106; and (2) the zip code stored in the nonsensitive terminaldata 341 of the payment envelope 301 matches the geographic zip coderestriction set by the consumer.

After verifying the consumer identity and payment transaction, theconsumer financial server 105 generates a transaction status messageindicating the status of the payment transaction—i.e., that the paymenttransaction is authorized, declined, or that authorization is withheldpending the receipt of further information. In 209, the transactionstatus message is transmitted to the payee financial server 103. Thetransaction status message can also be transmitted to the IdM service106 and/or the consumer computing device 101. In 208, the consumerfinancial server 105 can optionally obtain from the RKM server 104information useful for communicating with the payee financial server103, such as an IP address or a session token.

If the payment transaction is authorized, the payee financial server 103will memo post the payment transaction by creating a temporary databaserecord of the payment transaction in the payee's account. In the eventthat the payment transaction is not authorized, the payee financialserver 103 can route the payment envelope 301 to an alternate consumerfinancial account server listed in the instruction data array 315. Ifthe alternate consumer financial account also declines the paymenttransaction, or if no alternate payment accounts are identified, thenthe transaction is denied or authorization is withheld pending thereceipt of additional information. In 210, the payee financial server103 transmits the transaction status message to the payee computingdevice 102, which then transmits 211 the transaction status message andpossibly a receipt to the consumer computing device 101 for display tothe consumer.

Those skilled in the art will recognize that the embodiment illustratedin FIG. 2 is not intended to be limiting, and one or more steps can beomitted or altered, or the order of the steps can be altered, withoutcompromising the functionality of the systems and methods disclosedherein. For instance, if the consumer and payee utilize the same FSP, itmight not be necessary for the financial servers to communicate with aRKM server 104 to properly route electronic communications during apayment transaction. Additionally, if the consumer does not have anaccount with an IdM service 106, or if a payee is making a payment tothe consumer, then transmissions 202, 203 b, 207, and 211 b involvingthe IdM service 106 could be omitted. In that case, the consumercomputing device 101 could communicate directly with the consumerfinancial server 105 when transmitting the payment envelope 301 orreceiving consumer information and financial account settings andpreferences. In other embodiments, the consumer computing device 101 canreceive the transaction status message from only the payee computingdevice 102, from only the IdM service 106, or from both the payeecomputing device 102 and the IdM service 106.

The flexibility of the present systems and methods allows them toaccommodate a variety of payment systems and POS devices. To illustrate,if a merchant is capable of processing anonymous payments, the consumercomputing device 101 can transmit the payment envelope 301 and paymentrequest to an IdM service 106 and/or directly to the consumer financialserver 105, as shown in FIG. 7. The consumer financial server 105authenticates the consumer's identity and authorizes the paymenttransaction by comparing the data in the received payment envelope 301with data stored in a database on the server or with data in a paymentenvelope 301 received from the IdM service 106. If the transaction isauthorized, the consumer financial server 105 transmits a transactionauthorization 350 message to the IdM service 106 along with a paymentcode 360. The payment code 360 can be transmitted to the consumercomputing device 101 and then relayed to the payee orally orelectronically for redemption with a FSP in exchange for remuneration370. In this embodiment, the payee does not receive consumer datacontained in the payment envelope 301, so the identity of the consumerremains confidential and anonymous.

Another exemplary embodiment capable of processing anonymous payments isdepicted in FIG. 8. The consumer computing device 101 can transmit apayment envelope 301 and payment approval to an IdM service 106, whichtransmits the payment envelope to the consumer financial server 105. Theconsumer financial server 105 authenticates the consumer's identity andauthorizes or declines the payment transaction. If the transaction isauthorized, the consumer financial server 105 transmits a transactionauthorization 350 message to the payee financial server 103, whichtransmits the transaction authorization message 350 to the payeecomputing device 102.

In yet another embodiment illustrated in FIG. 9, the present inventioncan be used with a secure payment system where the consumer utilizes amerchant-specific charge account or merchant-specific consumeridentification and where the merchant securely requests paymentauthorization from the consumer's FSP without receiving a paymentenvelope 301 from the consumer. In this embodiment, the consumercomputing device 101 transmits to the payee computing device 102 apayee-specific consumer identifier 380 that is recognized by both thepayee and the consumer's FSP. The payee's backend system (e.g., theconsumer financial server 103) establishes a secure connection with theconsumer financial account server 105 and transmits a payment request390 with the payee-specific consumer identifier 380. If the transactionis authorized, the consumer financial server 105 transmits a transactionauthorization message 350 to the payee backend system, which transmitsthe transaction authorization message to the payee computing device 102,which in turn transmits the authorization message to the consumercomputing device 101. This embodiment eliminates any security risk posedby transmitting from the consumer computing device 101 to the payeecomputing device 102 a payment envelope 301 containing sensitiveconsumer data.

Skilled artisans will appreciate that the present systems and methodsare capable of accommodating the use of multiple payee financial serversas well as multiple consumer financial servers, as illustrated in FIG.10. Multiple payee financial servers can be used if, for instance, asingle merchant utilizes multiple FSPs; a payee computing device is usedfor multiple merchants; or a single payee FSP routes paymenttransactions through multiple financial servers. Multiple consumerfinancial servers can be used in instances where one payee financialserver processes payment transactions for multiple consumers withseparate FSPs, or when a single consumer utilizes a number of financialaccounts with separate FSPs. FIG. 10 also illustrates the distributednature of the present systems and methods in that payment transactionsare authorized without the need to route the transactions through acentralized card network.

Although the foregoing description provides embodiments of the inventionby way of example, it is envisioned that other embodiments may performsimilar functions and/or achieve similar results. Any and all suchequivalent embodiments and examples are within the scope of the presentinvention.

What is claimed is:
 1. A system for authorizing payment transactionscomprising: a first processor associated with a payee, the firstprocessor coupled to a first data storage device includingnon-transitory computer-readable medium with computer-readable code forinstructing the first processor; and a second processor associated witha payer, the second processor coupled to a second data storage deviceincluding non-transitory computer-readable medium with computer-readablecode for instructing the second processor; wherein when thecomputer-readable code is executed by the first and second processors,the first and second processors perform operations comprising: (a)storing, by a first processor, to the first data storage device, payeedata and associating, by the first processor, the payee data with payeetransaction data; (b) receiving, by the first processor, a first paymentdata envelope associated with a payment transaction, from a payeedevice, the first payment data envelope comprising a payee alias, apayee shared secret, and crypto data, including encrypted payee data andencrypted payee transaction data; (c) decrypting, by the firstprocessor, the encrypted payee data from the payment data envelope usingthe payee shared secret, retrieving, by the first processor, the storedpayee data using the decrypted payee transaction data and comparing, bythe first processor, the decrypted payee data with the retrieved payeedata; (d) verifying, by the first processor, a payee identity based onthe comparison; (e) based on verifying the payee identity, generating bythe first processor an IP address request message comprising a payeralias; (f) transmitting, by the first processor, based on theverification of the payee identity, the IP address request message to anRKM server; (g) receiving, by the first processor, a second-processor IPaddress from the RKM server; and (h) transmitting, by the firstprocessor, the first payment data envelope to the second processor usingthe second-processor IP address.
 2. The system of claim 1 wherein thefirst payment data envelope further comprises an instruction data arrayand the processors are further configured to perform the operations of:(a) receiving, by the first processor, from the second processor, atransaction status message having a transaction flag with a value ofauthorized or declined, wherein: (i) when the transaction flag has avalue of authorized, the first processor creates a temporary databaserecord of the payment transaction that is used to update a payee accountbalance; and (ii) when the transaction flag has a value of declined, thefirst processor transmits the first payment data envelope to a thirdprocessor based on the instruction data array.
 3. A system forauthorizing payment transactions comprising: a first processorassociated with a payee, the first processor coupled to a first datastorage device including non-transitory computer-readable medium withcomputer-readable code for instructing the first processor; and a secondprocessor associated with a payer, the second processor coupled to asecond data storage device including non-transitory computer-readablemedium with computer-readable code for instructing the second processor;wherein when the computer-readable code is executed by the first andsecond processors, the first and second processors perform operationscomprising: (a) storing, by the second processor, to the second datastorage device, a consumer PIN and biometric information andassociating, by the second processor, the consumer PIN and biometricinformation with consumer payment information; (b) receiving, by thesecond processor, a first payment data envelope associated with apayment transaction, from a payee device, the first payment dataenvelope comprising a payee alias, a consumer shared secret and cryptodata including encrypted biometric data, encrypted PIN, and encryptedpayment information; (c) decrypting, by the second processor, theencrypted consumer PIN, biometric information and payment informationfrom the first payment data envelope using the consumer shared secret,retrieving, by the second processor, the stored consumer PIN andbiometric information using the decrypted payment information andcomparing, by the second processor, the decrypted consumer PIN andbiometric information with the retrieved consumer PIN and biometricinformation; (d) validating, by the second processor, the paymenttransaction based on the comparison; (e) based on validating the paymenttransaction, generating, by the second processor, a transaction statusmessage corresponding to the validation; (f) transmitting, by the secondprocessor, the alias of the payee to an RKM server; (g) receiving, bythe second processor, an IP address from the RKM server; and (h)transmitting, by the second processor, the transaction status message tothe first processor using the IP address.
 4. The system of claim 3,wherein the processors are further configured to perform the operationscomprising: (a) receiving, by the second processor, a second paymentdata envelope from an identity management server; (b) storing, by thesecond processor, payer data to the second data storage device andassociating, by the second processor, the payer data with the consumerpayment information; and wherein (c) the step of authorizing, thepayment transaction further comprises the operations of (i) retrieving,by the second processor, the payer data, (ii) verifying a payer identityby comparing, by the second processor, payer data in the first paymentdata envelope with payer data in the second payment data envelope. 5.The system of claim 3, wherein the processors are further configured toperform the operations comprising: (a) receiving, by the secondprocessor, a second payment data envelope from an identity managementserver; (b) storing, by the second processor, payer data to the seconddata storage device and associating, by the second processor, the payerdata with the consumer payment information; and wherein (c) the step ofauthorizing the payment transaction further comprises the operations of(i) retrieving, by the second processor, the payer data, (ii) verifyinga payer identity by comparing, by the second processor, payer data inthe second payment data envelope with the retrieved payer data.
 6. Thesystem of claim 3, wherein the processors are further configured toperform the operations comprising: (a) storing, by the second processor,one or more payment restrictions to the second data storage device; (b)associating, by the second processor, the one or more paymentrestrictions with the payer; and (c) determining, by the secondprocessor, whether data in the first payment data envelope or a secondpayment data envelope complies with the one or more paymentrestrictions.
 7. The system of claim 6, wherein the one or more paymentrestrictions comprise a predetermined upper limit on the payment amount.8. The system of claim 6, wherein the one or more payment restrictionscomprise a geographic limitation on the location of the paymenttransaction.
 9. The system of claim 6, wherein the one or more paymentrestrictions comprise a limitation on the types of products subject to apayment transaction.
 10. The system of claim 3, wherein: (a) the firstpayment data envelope further comprises payment instructions; (b) thepayment information comprises a cost amount; and (c) the secondprocessor is further configured to perform the operations of (i)determining a payment amount based on the payment instructions and thecost amount, and (ii) incorporating the payment amount into thetransaction status message.
 11. The system of claim 10, wherein thepayment instructions include a gratuity amount and determining thepayment amount comprises the operation of adding the gratuity amount tothe cost amount.
 12. The system of claim 10, wherein the paymentinstructions include a discount amount and determining the paymentamount comprises the operation of subtracting the discount amount fromthe cost amount.